以下是Kafka的設計所帶來的限制：

1. Consumer Group裡的consumer數量 不能小於 partition 數量。不然就會有partition裡的資料對不到consumer。
2. 若各個consumer消耗資料速度不均，Partition的消耗速度會失衡。也就是有的partition已經消耗到最近的資料，但有的partition還在消耗之前的資料。
3. 搭配上之前所說：「Producer必須要自己決定要將資料送到哪個partition」，所以失衡的狀況無法透過Producer改善，又：「每一個Consumer只會同時bind一個partition」，所以，失衡的狀況無法藉由produer/consumer的round-robin來解決(*)。
4. 基於以上，每個partition實際上可以看成一個獨立的Queue。也就是說，雖然有partition，但沒有所謂跨partition的total order，也就是只能保證各個partition自己的local order。
5. 也就是說，若有一個AP會處理跨partition的資料，AP不能假設會依producer產生的時序取得資料，而只能假設從每個partition裡取得的資料是有按時序的 (Kafka有保證，若Producer先送到Partition的資料，在Partition裡也會排前面)。這就是在Day 3所講到，partition帶來的tradeoff。因此，若有total order需求的AP並不適合用Kafka。

簡單來說，Kafka假設，AP是不需要total order的；抑或是AP只需要by-partition的local order，只要適當的做好partition，那麼就可以維持好時序的資料消耗。

Kafka實際上也倚賴Zookeeper來儲存Partition的metadata，如同Day 5我們提到的常見作法。

以上，這是從partition的角度來看Kafka。明天就再從Replication觀點來看Kafka吧。

(*) (Update 10/16): Kafka有rebalance功能，若在Consumer group中新增Consumer，會觸動rebalance, 重新分配partition與consumer之間的對應關係。這樣有機會可以解決資料量失衡的問題。